Don't re-trigger twice Java validation when a Java file is saved. by angelozerr · Pull Request #500 · eclipse-lsp4mp/lsp4mp

angelozerr · 2025-05-14T19:46:07Z

Don't re-trigger twice Java validation when a Java file is saved.

This PR avoid sending (type=3 which means configFile changed)

[Trace - 9:33:16 PM] Sending notification 'microprofile/propertiesChanged'.
Params: {
    "type": [
        3
    ],
    "projectURIs": [
        "C:\\Users\\azerr\\Downloads\\demo\\demo"
    ]
}

which retriggers validation of Java files when a Java file is saved.

See redhat-developer/vscode-quarkus#1004 (comment)

file is saved. Signed-off-by: azerr <azerr@redhat.com>

datho7561

This works great and the code changes look good. I'd like to hear from Roland as well, but I think it's a good idea to merge this.

angelozerr · 2025-05-15T17:42:21Z

This works great and the code changes look good. I'd like to hear from Roland as well, but I think it's a good idea to merge this.

Great! Thanks @datho7561 for your feedback.

rgrunber

Definitely fixes the properties changed notifications. Just noticed one behaviour change we should be aware of. Is this ok ?

rgrunber · 2025-05-16T16:41:44Z

+
 		// validate all opened java files which belong to a MicroProfile project
-		triggerValidationForAll(null);
+		// triggerValidationForAll(null);


I think this breaks the following behaviour. You have a Java source file that defines configuration properties used in the configuration file. If those are added/removed, it affects some diagnostics :

Without this change

Screencast.From.2025-05-16.12-36-34.mp4

With this change

Screencast.From.2025-05-16.12-43-30.mp4

The diagnostics will not update when saving the config file, but they do update when continuing to type in the source file, or re-opening it. Are we ok with that ?

vscode-java does have a setting that causes this exact behaviour by default (ie. don't update opened document diagnostics when another source file being modified affects it). Mainly for performance gains.

I remember that I had the similar problem with IJ Quarkus.

I am pretty sure that if you save your application.properties a second time, it will work.

If it that it is because we load in cache properties (for checking validation on Java file) from the /target/application.properties and not from src/main/resources/application.properties.

I think we should load cache from src/main/resources/application.properties.

We will loose the computed variable from maven for instance declared in teh properties file, but I have never seen this usecase.

Saving a second time will not fix this. Validation isn't triggered. You either need to type, or re-open the file.

That's strange it is working for me?

Are you making changes and then saving or just hitting "Save" on an unchanged file ? Making changes will update the diagnostics but saving doesn't. Where would the validation come from when triggerValidationForAll is removed from didSave above.

Are you making changes and then saving or just hitting "Save" on an unchanged file ? Making changes will update the diagnostics but saving doesn't. Where would the validation come from when triggerValidationForAll is removed from didSave above.

Type a space and szve it twice.

I need to investigate more a proper fix.

Typing a space in the Java source file even without saving the file will update the diagnostics. Look at the video under "With this change" above! You can see just typing updates the diagnostics so that's fine. What I mean is that saving a file that has no changes doesn't update the diagnostics.

Sorry I mean tyep a space and save application.properried and do that twice.

It should update java diagnostics correctly, right?

You're right, it does work. Interesting.

Update: I mean for the first save, the MP LS responds with no diagnostics, but on the second save it returns the diagnostic(s). I guess it can't save + return the updates diagnostics at the same time ? I guess that's fine for now.

@angelozerr all that's left is to address my comment at #500 (review)

rgrunber · 2025-05-16T19:50:12Z

+
+			// Exclude resources in the main output location (e.g.,/ProjectName/bin)
+			IPath outputLocation = javaProject.getOutputLocation();
+			IPath outputFullPath = ResourcesPlugin.getWorkspace().getRoot().getFolder(outputLocation).getFullPath();


This isn't the full path.

You could compute the path relative to the workspace, in which case I don't think you need outputFullPath. you can do outputLocation.isPrefixOf(resourcePath).

If you want the absolute path on the filesystem, why not do something like javaProject.getProject().getLocation().append(outputLocation) which should be the absolute path. I've seen it used in some other places.

angelozerr · 2026-04-21T13:24:52Z

I close this PR in favor of #546

angelozerr added this to the 0.14.2 milestone May 14, 2025

angelozerr self-assigned this May 14, 2025

angelozerr added the bug Something isn't working label May 14, 2025

angelozerr mentioned this pull request May 14, 2025

Autobuild triggers unnnecessary validation of all opened Java source files redhat-developer/vscode-quarkus#1004

Closed

rgrunber self-requested a review May 14, 2025 20:04

angelozerr force-pushed the properties_changed_on_jdt_improve branch 3 times, most recently from c1c1a36 to 9cf25a0 Compare May 15, 2025 04:32

angelozerr commented May 15, 2025

View reviewed changes

Comment thread ....eclipse.lsp4mp.ls/src/main/java/org/eclipse/lsp4mp/ls/java/JavaFileTextDocumentService.java Outdated

Don't re-trigger Java validation for all opened Java files when a Java

ec88978

file is saved. Signed-off-by: azerr <azerr@redhat.com>

angelozerr force-pushed the properties_changed_on_jdt_improve branch from 9cf25a0 to ec88978 Compare May 15, 2025 14:59

datho7561 self-requested a review May 15, 2025 15:15

datho7561 approved these changes May 15, 2025

View reviewed changes

rgrunber reviewed May 16, 2025

View reviewed changes

datho7561 modified the milestones: 0.15.0, 0.15.1 Dec 5, 2025

datho7561 modified the milestones: 0.16.0, 0.16.1 Dec 16, 2025

angelozerr closed this Apr 21, 2026

angelozerr removed this from the 0.16.1 milestone Apr 21, 2026

Conversation

angelozerr commented May 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

datho7561 left a comment

Choose a reason for hiding this comment

Uh oh!

angelozerr commented May 15, 2025

Uh oh!

rgrunber left a comment

Choose a reason for hiding this comment

Uh oh!

rgrunber May 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

angelozerr May 16, 2025

Choose a reason for hiding this comment

Uh oh!

rgrunber May 16, 2025

Choose a reason for hiding this comment

Uh oh!

angelozerr May 16, 2025

Choose a reason for hiding this comment

Uh oh!

rgrunber May 20, 2025

Choose a reason for hiding this comment

Uh oh!

angelozerr May 20, 2025

Choose a reason for hiding this comment

Uh oh!

rgrunber May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

angelozerr May 20, 2025

Choose a reason for hiding this comment

Uh oh!

rgrunber May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rgrunber May 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

angelozerr commented Apr 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

angelozerr commented May 14, 2025 •

edited

Loading

rgrunber May 16, 2025 •

edited

Loading

rgrunber May 20, 2025 •

edited

Loading

rgrunber May 20, 2025 •

edited

Loading

rgrunber May 16, 2025 •

edited

Loading